Your code is not quite OK, it should be without quotes (") like this:
# FULL: Comma-separated lists achievable ranks
LicenceRanksText=Débutant, Confirmé, Bronze, Argent, Or
# FULL: Comma-separated lists of points for each rank
LicenceRanksPoints=50,100,200,400,800The other problem is also apparent from the code - ranks (from points), just as licences (lap time) and safety ratings are in textual form available only in the FULL Airio version. That means you may use points in whatever way you wish, but defining ranges, assigning textual descriptions and using those to limit race joining (e.g. by car category) is not available in the FREE compile.
With these your settings races will restart after 30 minutes and only if there are 42 drivers - meaning never.
Use RestartTime=0 to disable auto-restarts, or turn off advanced checks (!cha off) for the more serious racing, which also stops auto-restarting.Your SRV setup looks good, custom grid is used, first 12 from last race are reversed, the rest keeps their positions, then follow non-finishers and newly connected basically in random order. LFS server grid setting does not really matter in this case, default LFS arrangement is simply overwritten by Airio.
I believe the command (to clear all championship data) is perfectly OK, problem could be you do not have sufficient rights to manipulate with statistics. See EnableStats item in CFG file and if it is higher than 4 then change it to 4 or define yourself as Limad5 to have super-admin rights incl. stats manipulation.
I double checked, all MSG files in Airio archives are positively UTF-8, all their special characters will be displayed correctly in Airio. I'm pretty sure of this, it is working for months without problems.
In case special chars are not processed OK, almost certainly the MSG file is not UTF-8 anymore. For example TCAdmin panel will save the file as ANSI if you use it for quick editing, so you do not want to do it.
Please download the original MSG (2.3) again, upload, do !rld, it must work...
It would be very bad application if it could not display such characters. Airio fully supports all European languages incl. Russian and Greek. Just make sure the MSG (and also CFG/SRV, if you have custom text there) is saved as UTF-8 and not ANSI. The link above is ANSI and if you just use it, the display would be bad. Save it again as UTF-8, upload, type !rld, it will work...
EDIT: Hmmm, it looks the above link contains file completely without ä, ö, ü, which certainly is not OK. My suggestion is NOT to use the adapted GE translation in the form it is, it has some serious flaws...
Last edited by EQ Worry, .
Right, the AllowNoKick=6 was the reason. This your setting means no one is protected from being kicked/banned by Airio for various reasons, not even admins (Limad4 or anyone connected with server password, such as the host) and supads (Limad5 and at the same time with server password), also no one can remove people from start grid then. My opinion? Very strange value you have there. 
PS: In case you wonder about supads... I just made up that word, it stands for super-admins (similarly as limads stands for limited admins). Let's see how long it will take before this word makes it into Webster's Online Dictionary.
PS: In case you wonder about supads... I just made up that word, it stands for super-admins (similarly as limads stands for limited admins). Let's see how long it will take before this word makes it into Webster's Online Dictionary.
The links look OK to me on the www.airio.eu site, which is the only one I keep. Direct download of the current version is right here. If you have any questions/trubles with setup, do not hesitate to ask e.g. via MSN.
Hmmm, highly interesting, trying to ban the host. What value you have as AllowNoKick in CFG file? If you're using 4 or lower this should not happen. Anyway, I updated the check a bit so that admins can always remove people from start grid... One more question, what value you use as IsAdmin, also in CFG file?
What value you have as AllowNoKick in CFG file? If you're using 4 or lower this should not happen. Anyway, I updated the check a bit so that admins can always remove people from start grid... One more question, what value you use as IsAdmin, also in CFG file?Ah, took me quite a while to see what you mean!
You skip a track in rotation manually, but this action is not recogized, and after next race end the same track is loaded. Tracks go out of synch with rotation definition. OK, noted, I will correct this behaviour, it shouldn't be that complicated. Thanks for spotting this! 
While you know I do not want to go too far with variables, I guess (hope) a few would not hurt. 2.3.3 contains the variables you mention as well as support for custom user commands (output shown only to one driver).
Hi!
Please check what setting you use under EnableStats in CFG file. This says to whom stats manipulation commands (such as !imp) are available. By default there is level 5, while server admins (including the host) have only level 4.So please either change EnableStats to 4 or define yourself as a super-admin in CFG file like Limad5=your_name. After !rld and/or reconnect the !imp and !exp should work for you.
I will change the value to 4 in default configs, because it is confusing as it is now, so thanks for pointing this out!
Last edited by EQ Worry, .
Aaahhh, grrr, you cannot. Can you wait say a week for 2.3.3 then? I could ask Franky to update the update
, but this is really minor thing... I'd like to wait a few more days for any bug reports or smaller feature requests and then make 2.3.3 a "stable" release, as it was required by some...@ VoiD & Crady : You're right about limited usability of the current pit entry/exit check, it works good only on some tracks. For a perfect check support for some polygon the shape of pit lines would be necessary plus the first/last node. Possible? Yes. Hard to implement? Not really. Hard to configure? Quite, but only once. I guess I will put this on my TODO list, overall it could be a nice touch.
@ jvalley : Man, thanks for your kind offer. I'm afraid I will have to update docs myself, but any attempt to make a quick reference guide is most welcome!
@ michele : Of course you're right, my bad, I forgot about the option to use Previous and Following buttons. I did minor correction, it should be OK now. Please download again the 2.3.2 archive, check the EXE has today's timestamp, and overwrite the old EXE/PDB file. Test and let me know if it is behaving correctly. Thanks!
@ jvalley : Man, thanks for your kind offer. I'm afraid I will have to update docs myself, but any attempt to make a quick reference guide is most welcome!
@ michele : Of course you're right, my bad, I forgot about the option to use Previous and Following buttons. I did minor correction, it should be OK now. Please download again the 2.3.2 archive, check the EXE has today's timestamp, and overwrite the old EXE/PDB file. Test and let me know if it is behaving correctly. Thanks!
Right, I guess this is a result of some misunderstanding. Pitlane exit/entry check works in conjunction with entering/leaving proper racing path as defined by LFS developers and as seen e.g. in Remote (the Track option there).
On some tracks the on/off path info can be used to improve pit exit/entry practice. But it is not a perfect solution, because sometimes the racing path intersects with pit lines (blend lines, called by some). So what you need to find is the earliest track node where a car can enter racing path when exiting pits or leave the racing path when entering pits.
This is not the same as driving to the end of pitlines, the check can be used to prevent pitlanes cutting only to some extent, depending on specific track. For example on BL1 the pit lines end exactly on the racing path, the check runs ideally there. On AS2 the racing path crosses drawn pitlines in about half of their length, the rest cannot be enforced by this relatively simple check.
The good news is that proper node settings can be made just once. Crady has created initial settings. (Thanks a lot!) They are not all tested thoroughly but they should be good for default track layouts. Add the contents of the appended file somewhere to the end of TCD file and then try some heavy, medium and none cutting on pit entry/exit. Just note that bad pit entry warning appears only after you actually enter the pitlane, not immediatelly.
Ehm? I'm not sure what you mean, pitlane entry/exit penalties are always just question on entering/leaving proper race path.
Aaaah, you're right, that is a bug! I'll try to provide the solution ASAP. Thanks for reporting this, it is a side effect of one added feature.
EDIT: The solution was simple, the Airio 2.3.2 archive now contains updated EXE and PDB files and clearing the DT penalty should be possible without side effects.
Last edited by EQ Worry, .
You're right, this message causes some confusion, I will change it a bit. Note that you may turn off this message for yourself (just as the yellow flag announcement) by deselecting Private data personal option (in 2.3.2+).
I don't think you're right here. It is indeed kick for security, because impossible speed could be achieved by hacking. So kick is for security, spectate would be for safety, but i'm not sure if there should be admin option to choose between the two, because this filter doesn't fire as much.
Right, thanks! I'll go through the language file and if nothing of 2.3 is missing, I'll make it available in language pack and complete distribution.
Well, I was trying to evade this solution, for quite some time now. Of course splitting the message is possible, but I felt translators should try to use short items that fit into one line, because otherwise this may increase spamming.
But by many people this LFS limitation is seen as Airio defect, so I've given up.
Into 2.3.3 I've implemented global message (such as speed, split, spec) splitting in case it cannot fit into one line. This is of course language-dependent, so some people may see one line while oher will have two, if they have that info display selected at all...Oh? Sorry, this is a bit surprising view for me, for several reasons:
1) All recently implemented features make sense, there's always someone using them to full extent. What I'm strugling with are some principles introduced at the beginning, such as the total/champ data.
2) If there's a bug found (either by me or reported), I usually correct it at once. That is also partly the reason for so many updates. And the most important - currenty known bugs: NONE. Bugfixing is my primary task, I hate any kind of bug, however small.
3) The red line is to offer as complete and as flexible admin/driver system as reasonably possible, all that without scripting, just through described configuration items.
Uhm. About 18 months ago when I started developing Airio from scratch, I was just experimenting, having fun trying to add this and that, all hard-coded. Then suddenly it was possible to use the tool on AirAttack servers and I was adding more things. There was never any plan where it should go.
Some 12 months ago it was clear external configuration is needed, even if used just one one site. Then common stats, localization, all this was coming suddenly, as suggestions for improvements. When I wanted to make Airio public, because I thought it could be used also elsewhere, I had to add more customization options and change internal arrangements.
All this was done intuitively, based on experience of what is good and usable. When Airio went public some 6 months ago, many deficiencies were pointed out, many requests made, some bugs reported. All this was processed and today Airio is, in my opinion, pretty complex system, yet very stable and reliable, while still admin and user friendly.
The concept is to go forward this way...
I'm no development manager having milestones set and a plan to follow. I'm just an amateur programmer having fun introducing new concepts at a time when serious LFS developemet has to a large extent (sadly) stopped completely.Yes, documentation is my weakest point. It is in version 2.1, but the 20 intermediate releases changed many things. Problem is updating or rewriting docs takes so much time and is so boring.
It is much easier to keep good changelog and reasonable decriptions in configuration files. But of course I want to update documentation. One day...While it may seem as easy thing to add changelog into every new release, it is always some additional work, requiring synchronization with hard-to-update results. I really prefer the online version.
As mentioned above, there are currently no known/reported bugs. Concerning accepted requests there is the TODO list at the end of the changelog page. It tries to show the order in which things may be implemented in the future, but it is very inaccurate at times.
Well, I'm trying to keep it that way, both the FREE and the FULL version. Also this is expressed in the number of updates, with each one also adding some extensive new/original things. But I guess I can see your point, to a certain extent. I think it could be summarized like this: FFS, stop this update madness, give it some time to settle, to show what's good and what's bad. OK, I'll try to do that, but you know, I'm driven... like the snow... pure in heart... driven together... and driven apart. 
(Anyone recognizes this one?)Ouch, come on Crady, this was a bit like a blow below the belt. True, I prefer to call Airio a tracker, but we all know what we're talking about.
Man, surely that's worth mentioning! Stupid me, I never thought of races with total time longer than 1 hour.
Well, to say the truth I cannot imagine how the behaviour you describe could be possible, but certainly hours will be cut from display. Latest compile (still called 2.3.2) contains a fix. You asked about 5 times for the past month so there it is. Sorry for the delay! PTH support needed some after-release updates to be more reliable/usable, that's why the delay. Mail to FULL version users (and to Franky of 500servers) will follow shortly (minutes) after this post.
The initial 2.3.2 release had some small deficiencies. I did a quick update, meanwhile adding one more feature, the possibility to check correct pitlane entry, not only pitlane exit. Ah, also incorrect entry/exit can be now penalized as you wish. To get the new things, just download 2.3.2 again...
Bad news (for some), good news (for others): Airio 2.3.2 is released. All updates are summarized in the changelog, but here's a few interesting things:
Enjoy or ignore.
- Added support for path data (supplied by LFS developers). Proper racing path can be checked now (with definable allowances), proper entry from pits (on some tracks) and also idling outside the track may be allowed.
- 14 common spectate reasons are now shown also in big buttons. Their default messages can be detailed using custom localizable texts. Good for providing e.g. additional info on tyres required, how to make better online PB or what car class to start with.
- Added !grid command displaying expected restart grid (incl. data used for sorting). Added !rsb and !rtb commands showing PBs only of registered people (similar to Lapper's !topqual).
- There are three additional personalization options (allowing among other things to turn on/off the much hated "You have caused yellow flag" message).
Enjoy or ignore.
Hi! You're welcome. Thanks for using this tool!
Hm, I realize there's been too many updates recently. So many it may be tiresome to be up-to-date constantly. But you know, I'm receiving requests for features and bug reports, and when I add something substantial or asked for, naturally I try to make the new things available immediatelly. Some people are always waiting for them. Then occasionally some bug reports start to come back and always ideas for improvements and a new cycle starts.
Recently (I mean last 12 updates or so) the config changes were always minor, usually some items added, rarely some moved to another file or removed completely. All these config updates can be done in 5 minutes, you just need a file comparison tool and compare your current config with new default config, which will show you nicely what new items are there and where.
I am myself updating configs of 2 server groups and I'm always done in 5 minutes or so. Download current used configs, open CFG, TCD and SRV files one by one in PSPad, compare the files with new defaults in Airio achive, copy new items to old configs, save, upload, reload. It really takes just a few minutes, including EXE and PDB files update. If you have several servers under one Airio, you are updating CFG and TCD files just once, also SRV, only sometimes copying new items into SRV.X files is you require different setup on a certain server.
Now if you run multiple Airio instances, then of course the effort multiplies. In that case consider if it would not be better to combine the servers under one or two instances, updating will be much faster then.
I personally do not see any advantage in having one BIG new release say once a month, instead of 4 smaller ones every week. If you'd prefer that, just ignore some 3 smaller releases and make a jump say from 2.2.8 to 2.3.2 once a month. The faster releases allow me to quickly solve all discovered troubles, correct some inconsistencies, implement small improvements and such.
Consider my very current situation: Some people asked for possibility to penalize/spectate drivers for cutting pit exit lines. So, in order to make this available I implemented a new feature reading proper racing path from PTH files (supplied by LFS developers). Then I added routines checking if the car is on the racing path. If not, a PB done in that lap may be ignored, because it was achieved by some cutting. In my view, pretty cool feature.
With additional definition it is possible to make sure cars return from pits to racing path in proper places as shown by pit exit lines. Also nice and requested. Knowing racing path also allows to let people idle when off the path, e.g. when struggling in gravel to get back to track. Also usable.
Using PTH data also some additional info can be output using !track command – exact length, path width, height changes. Some people suggested !grid command showing expected restart grid when custom sorting is used. So I added this including data usable for checking why the grid looks that way. Someone else requested a command mimicking Lapper's !topqual. So I added this as well.
With all the above and some fixes I think this makes a nice new release. I see no point in delaying this release for another 3 weeks just not to be so active. If you do not care about that features, ignore the release, wait for features or fixes that are important or interesting to you. Then do the update, changelog always mentioned all thing fixed, changed. If you like the features and want to test them, then you need to update some files. But really, it takes just 5 minutes.
Well, the intrinsic problem is new releases fix old bugs, but introduce new things as well, that may contain new bugs, so then comes next release with fixes, but also new features and there we go... I tried to make 2.3.1 and upcoming 2.3.2 as fixes-only, but see where it ended. I guess my forward momentum is too strong, but when I have a request and I see the way to go, I'm trying to implement it.
Problem is there are really no special stable versions. Every release is in my eyes stable, or I would not make it available to everyone. There may appear bugs, of course, as in every software, but such may be contained in any version, regardless for how long it has a "stable" mark.
I'm not sure I understand the config files idea. There's one thing I could do, I guess, and that is to make special Airio.cfg.xxx.txt and Airio.srv.xxx.txt files where xxx is current version number. These files will contain all new config items and you may copy them into current configs or include them using IncludeFile directive.
Personally I wouldn't use the files as includes, because it time you can have several config files with items spread more or less randomly, but it may be an improvement for some. Update can be done fast, consolidation left for some other time.
One more note: When doing regular updates it is sufficient to replace EXE and PDB files, Airio will then use its default settings (usually reasonable) for any items not found in config files. Currently any 2.2.x -> 2.3.x update should be done by comparing config files. With versions 2.1.x and earlier basically complete reconfiguration using new files is necessary, there's been substantial changes in their structure...
No, that is not possible. The rating settings are server-specific, not track/car specific.
Ah, that explains the different time adjustments.
Note that Airio by default uses different GT2 cars restrictions, lower ones. Anyone is free though to change those as needed and create completely new custom cars. And good job, Okram, with the calculations. 
Done, !axs command is implemented, requiring one parametr, name of the layout.
Well, actually there was a little bug in the !axi command output, cutting 1st line and completely hiding others.
Corrected now. Output still goes to chat, but it is complete, uncut.I'm not sure, but maybe layouts loaded from client behave differently, maybe only layouts stored on host and loaded from there are reported by server as Airio expects. You can always type !track and see if Airio sees a layout loaded. In that case it will start to store stats for this new "track"...
Aaaahhh, right. After some testing the cause is clear - wrong string case handling. I did a small update fixing this and also the same max speed reported 4 times in layouts...
Oh? I really hope that would not be the case, because when I was checking this last time it was working OK. Also I tried this on your server and it seemed OK to me, my stats were correctly reported and saved.
Yes, good logic.
It may be worth to check a few previous splits as well to see if the slower (XFG) and faster (RB4) cars were one right after another. I believe Airio system log is not as hard to comprehend and it really allows you to look back in time and deduce many things.OMG, so sorry.
It was a bit surprising though. I didn't read the link properly, there was just a mention about oval... Ah, that's good, nice usage!
I know other people use the time filter to disallow drafting even with oval races... I guess also the maximum allowed speed filter can be used for that.Wow, nice numbers, Okram! One thing baffles me though: In your calculations the FZ2 time adjustments are around 10 percent. But what restriction was used on CTRA? I know that with 20 percent intake air restriction the FZR -> FZ2 time adjustmets are 5 or 6 percent, not 10%.
LapsPoints defines how many laps (in percents) must people complete in race comparing to winner to get some points for the race. If you use 0, then even people completing just 1 lap may get points. Default setting is 80 meaning that to get points for a race for 5 laps you need to complete at least 4 laps.
I'm not quite sure what you mean... Without InSim (such as Airio) you cannot force people to use certain restriction, except by displaying restrictions (F11, I think), listing (TAB) through people and telling everyone what they should do.
Yes, oval racing is known to breach the "possible lap/split/sector time" quite often, due to heavy drafting. However, by default the time-check filter does not run (see CheckTime in SRV file), it is just ready as a means to fight speed hacks, if some appear.
Two possible solutions: Do not run the time check on the server, or use lower possible split/sector times, just as you did. However, even with allowed time of 98 percent of WR there's a strong risk someone would be kicked. So I'd suggest to turn off the filter completely.
FGED GREDG RDFGDR GSFDG